Method and system for storing data

ABSTRACT

A method is universally applicable, enabling storing all types of data and structures of data. The method is based on structure elements being self-contained information carriers, represented by pairs of concept and concept value and associated context information. Using the method, data can be organised in hierarchies of structure elements with arbitrary depth and complexity. In spite of its simplicity, the method can reflect connection, context and meaning, however complex, irrespective of types of data and how complex the relations between data may be. Hence, the method represents a fundamental framework for standardised physical data storage of all types of data.

This application is the National Phase under 35 USC §371 of PCTInternational No. PCT/SE01/00429 which has an International filing dateof Feb. 28, 2001, which designated the United States of America andwhich claimed priority on Swedish application number 0000647-8 filedFeb. 29, 2000, the entire contents of which are hereby incorporatedherein by reference.

TECHNICAL FIELD

The present invention generally concerns a method for defining, storing,retrieving and interpreting data, as well as a database system, in whichdata is stored according to the method described.

BACKGROUND OF THE INVENTION

Electronic data processing requires storing structures of data. Ingeneral, such data stored in such structures is called a DATABASE. Anumber of methods are available for this purpose. Most such methodsassume a predefined structure type called RECORD. A record describes anobject or an event with a number of ATTRIBUTES connected with it. Anattribute is a concept expected to receive contents. According totradition the attributes are contextually connected with a record typeand hence are not self-contained carriers of information. In a database,data is stored according to record definitions. Each record typereflects a LOGICAL FILE to contain objects or events being describedaccording to the record definition. A database is a set of such files,fulfilling a certain purpose. A DATABASE SYSTEM is a set of generalmethods, preferably implemented with programmed software, with thepurpose of defining, maintaining, retrieving, and, to some extent,interpreting data in a database.

A common feature of most database systems is that they effectively canaccess data on the computer's SECONDARY DATA STORAGE (e.g. hard disk).The secondary data storage of a computer uses BLOCK-addressing whenaccessing data, and is suitable for permanent storing of data. To obtaineffective use of secondary data storage, the possibilities of modifyingthe database definitions must be restricted.

Some structure types are not suitable for traditional database systems.They depend on the computer's PRIMARY DATA STORAGE (e.g. Random AccessMemory) to obtain effective access to data. The primary data storage isBYTE-addressed and very fast. However, the primary data storage is notsuitable for large databases or permanent data storage. DYNAMIC RECORDTYPES is an example of such data types. A dynamic record type can bedefined and redefined without affecting existing programs or data. Forthis type of structures, access mechanisms and context are normallyimplemented as part of the application program. To achieve effectiveaccess to such data, all data need to be accessed in the primary datastorage, whereas the secondary data storage is exclusively used forpermanent storing of the data.

Program products storing large quantities of data need to access data inthe secondary data storage. For this reason they are limited to fixedrecord definitions. Hence, in the process of meeting needs for increasedsoftware functionality, record definitions have to be enlarged andassociated procedures have to be updated or added successively. For thisreason standard software tends to get out of proportion. This phenomenonis well illustrated by standard application software for businessadministration (Business systems). The software flexibility is increasedby adding new program modules, each reflecting a new aspect of thebusiness. However flexible the software, the user has to comply with thesoftware properties and limitations. The possibilities of adjusting thesoftware to suit the needs of the user are truly limited. Large portionsof the business rules are predefined in the software and can bedeveloped only marginally. Many phenomenona appearing naturally in acertain business are excluded from being described within the frame ofthe software.

A solid reason for this is that the basis for describing objects, eventsand the domain of rules is determined by the predefined data structureand the corresponding software. Therefore, a more flexible system forphysical storing of data, less dependent on predefined data structuresand procedures is desirable.

Further, the current methods for storing data occupy large memory space,as the storing density normally is very low. This is due to the factthat the record definitions are excessive in comparison with the needsof the user.

Other problems with the current database systems are long data retrievaltimes, difficulties with modifications of the database and the interfaceto it. Further, combining data from different databases is complicated.

SUMMARY OF THE INVENTION

An object of an embodiment of the invention is to provide a method fordefining and storing data, and data retrieval as well as a correspondingdatabase system, which wholly or partly eliminates a problem in theprior-art methods.

An embodiment of the invention concerns a method for defining, storing,retrieving and interpreting data, in which data is represented inself-contained carriers of information, called structure elements,comprising a data element which in turn comprises a concept (CPT) and aconcept value (INS), the structure elements being stored in a structureelement file. Particularly, the structure elements further are assignedan identification element (SID), enabling unique identification ofstructure elements, and at least some structure elements are assigned aposition element (OWN; ATR; SRT), determining the context of thestructure element. An embodiment of the invention also concerns acorresponding database system.

File shall here be understood in such manner that it can be storedphysically on an arbitrary block-addressable data storage, such as acommercially available secondary data storage. Further, several filescan be stored in one physical device.

An embodiment of the invention offers a flexible and effective methodfor storing and retrieving data, and it offers a number of advantagescompared with prior-art methods. Among other things, an embodiment ofthe invention offers a very compact database with high data density, thememory space being effectively utilized, and, in particular anembodiment of the invention enables effective data storing and retrievalon a block-addressable storing device. Further the method is universallyapplicable and the structure elements are independent of data types.Further, with an embodiment of this invention it is simple to define andredefine concepts and concept structures, e.g. “Data Dictionary”. TheData Dictionary can be expanded while an application using it is inoperation, whereas the database is totally dynamic and governed byactual needs. Hence, an embodiment of the invention enables defining anddeveloping, among other things, dynamic record types with no need forreorganizing data or modifications of existing software programs usingthe data. The method according to an embodiment of the invention offersa number of entries for structure element retrieval.

Further it is preferred to store data in files for text elements andaccelerator elements. These additional elements are stored, preferably,as flat tables, i.e. not hierarchically, each in its own file,reflecting portions of the information stored in the hierarchicstructure element file. These complementary elements facilitate enhanceddata interpretation and faster retrieval and processing.

Particularly the text elements preferably comprise text associated withdata stored in the corresponding structure element(s). As a result, thetext elements are well suited for presenting structure element data thatrequires a textual interpretation. Further, the text file can be used asa retrieval path to the structure element file.

Particularly the accelerator elements preferably comprise clusters ofdata from several structure elements, enabling effective data retrievalin the structure element file based on compound conditions representedby the content in two or more structure elements.

Software using data stored according to an embodiment of the inventioncan hereby establish a set of concepts and concept values, interpretableby the software. Further, the domain of concepts can be developed withcontents and associated procedures within frames determined by thesoftware. This makes it possible to develop general tools forapplication system development.

BRIEF DESCRIPTION OF THE DRAWINGS

Further advantages and distinctive features of the invention will beseen in the claims and the description of preferred embodiments.

The enclosed drawing shows in FIG. 1, a block diagram of the logicalrelations between the element files according to a preferred embodimentof the invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

An embodiment of the invention concerns a method for defining, storing,retrieving and interpretation of data, and a corresponding databasesystem, to be built according to the method of an embodiment of theinvention.

A fundamental property of an embodiment of the invention is regardingdata as pairs containing a concept and a concept value (Concept;Value).Thus, every structure element becomes a self-contained informationcarrier. Example: (PERSON; “Adam Smith”) and (AGE; 54). Such structureelements can be connected vertically in Parent/Child-relations, wherethe Child-element can be interpreted as an attribute of theParent-element. Thus a hierarchic context-structure is created. Thus, inthe example above (PERSON; “Adam Smith”) has the attribute (AGE; 54),that is, (AGE; 54) dwells in the context (PERSON; “Adam Smith”). Hence,a record, as used by conventional database systems, using an embodimentof the invention can be replaced by a concept represented by a structureelement, having one or more structure elements connected to it asattributes. The method according to an embodiment of the inventionallows such structures of arbitrary vertical depth, and it allowslikewise an arbitrary number of different attributes on each verticallevel, and it allows an arbitrary number of values of each attribute oneach level.

The Structure Element

Hence, according to an embodiment of the invention, data is arranged insuch self-contained structure elements, which are stored in a structureelement file as shown in FIG. 1. A structure element comprises a dataelement, and this in turn comprises a concept, CPT, and a concept value,INS. Further, the structure element comprises an identification element,SID, being the primary key for the structure elements, enabling uniqueidentification.

Further a structure element comprises a position element, used forcreating and interpreting relations between structure elements. In thisway contexts are created. The first part of the position element, OWN,contains information concerning vertical relations between structureelements, and a hierarchy of structure elements can be created. TheOWN-property of a structure element contains the SID of itsParent-structure element.

Further, the position element contains a second part containinginformation concerning horizontal relations between structure elements,denoting the relations between structure elements on the same hierarchiclevel. This second part comprises two horizontal position properties, aprimary positioning, ATR, that can be interpreted as attribute and asecondary positioning, SRT, that can be interpreted as anattribute-value positioning. The position properties organise thestructure elements in the structure element file on each level of thestructure element hierarchy.

The last property, SRT, can preferably be used for validating differentvalues of an attribute using context defined by other structureelements. Such an application of the invention is illustrated in theexample below.

Hence, the structure elements have six (6) properties, which can bedivided in three (3) categories: Identification, Position (context) andData. The structure element properties are shown in the table below,where the format preferably can be numeric:

Field# Field name Explanation 1 SID Structure element identity 2 OWNParent-concept SID. Vertical structure 3 ATR Attribute. Primaryhorizontal position 4 SRT Attribute value sequencing Secondaryhorizontal position 5 CPT Concept 6 INS Instance (concept content)

The identification, SID, can preferably be an integer, identifying anoccurrence and serving as a primary key for the structure element file.The vertical position property, OWN, contains the primary key to theParent structure element. This property of the technique createsvertical Parent/Child relations. The first horizontal position property,ATR, can preferably be an integer ordering Child-elements, being usedfor ordering attributes. The second horizontal position property, SRT,can preferably be an integer ordering Child-elements with the same ownerand attribute but with different values (INS) of the concept (CPT)declared for the attribute. This can be used for ordering multipleattribute values, often referred to as “repeating group”.

The vector {OWN,ATR,SRT,CPT,INS}={0,0,0,n,m} is called a basicoccurrence, which is the occurrence on the highest level of a hierarchicstructure of concept CPT=n with the contents INS=m. All structureelements, being defined with attributes, text representation oraccelerator representation, must have a basic occurrence. This will bedescribed in more detail in the following.

Retrieval Mechanisms for the Structure File

There are several possible ways to retrieve individual structureelements in the structure element file as described above. One way, inthe following called INDEX 0, is direct retrieval using theidentification (SID) in Field# 1. An alternative, in the followingcalled INDEX 1, is applying indirect retrieval via the vector {OWN, ATR,SRT, CPT, INS}, that is Field# 2, 3, 4, 5 and 6. Yet anotheralternative, in the following called INDEX 2, is applying indirectretrieval using the vector {CPT, INS, ATR, SRT, OWN}, that is Field# 5,6, 3, 4 and 2.

The access mechanisms for the elements of the structure element file arelimited by the properties of the structure elements as described above.Using the primary key (INDEX 0), it is easy to retrieve a Parent-elementof a Child-element. INDEX 1 is an effective mechanism for findingChild-elements in the structure hierarchy. INDEX 2 is suitable forretrieving specific concepts and concept values traversing the structurehierarchy.

Further, the method according to an embodiment of the inventioncomprises two additional elements, completing the method. These elementswill be described in more detail in the following.

Depending on the quantity of data and its character, the properties ofthe structure element may prove insufficient. In this case the TEXTELEMENT or the ACCELERATOR ELEMENT, described below, can be used.

The Text Element

Data in the structure element file, best being represented by text, canconveniently be completed with text element(s) in the text element file.A text element is related to a basic occurrence in the structure elementfile, as described above and as shown in FIG. 1.

The only purpose of the text element is transforming the numericrepresentation of data in the structure element into a textrepresentation. The text element, according to an embodiment of theinvention is used to retrieve, order and present data in an alphanumericformat.

The access mechanisms of the text element should be programmed in such away that text elements are stored and retrieved statically ordynamically. Static implies that references to text elements arepredefined in the software. Dynamic implies that programs using themethod according to the invention can accept instructions as to how touse text elements.

It should be noted that, to use text structurally, texts must becategorised with reference to concept definitions and be represented,preferably numerically, in the structure element file. This indicatesthat text element strictly is a mechanism for presentation and access.

For identification purposes, the text elements preferably compriseproperties corresponding to those in the structure element. Theseproperties are CPT and INS, identifying a basic occurrence in thestructure file. The text element also preferably comprises a property toensure uniqueness (UNQ) in the case where more than one basic occurrencein the structure file have the same text representation. The textelements also comprise a text property, holding the text representation(TXT). Other properties of the text element are an index (IDX)preferably used for defining several text representations to onestructure element, and a property used for defining several textalternatives to a certain text representation (ALT).

The properties of the text elements, preferred terms and field sequenceare presented in the following table, where the formats preferably canbe numeric and alphanumeric:

Field# Fieldname Explanation 1 CPT Concept 2 INS Concept instance number3 IDX Text representation definition 4 ALT Alternative textrepresentations 5 UNQ Optional for element uniqueness 6 TXT TextrepresentationAccess Mechanisms for Text Elements

There are several ways to retrieve individual text elements of the textelement file, as described above. One way, in the following called INDEX1, is applying indirect retrieval using the vector {CPT, INS, IDX, ALT},that is Field# 1, 2, 3 and 4. Another way, in the following called INDEX2, is applying indirect retrieval using the vector {CPT, IDX, TXT, UNQ},that is Field# 1, 3, 6 and 5.

The access mechanisms of the text file have the following purposes:INDEX 1 connects a basic occurrence in the structure element file withone or more text representations, whilst INDEX 2 is used for retrievinga basic occurrence in the structure element file using a textrepresentation.

The Accelerator Element

To increase retrieval effectivity in the structure element file, themethod according to the invention further comprises an acceleratorelement, referring to a number of attributes (direct context via therelation) or other structure elements (indirect context, preferablydefined in the application). Together, the attribute references identifya basic occurrence in the structure element file. The acceleratorelements are stored in an accelerator element file as shown in FIG. 1.The objective of the accelerator element is enabling a basic occurrencein the structure element file using references to data in severalstructure elements simultaneously. Using several structure elements,compound retrieval sets can be constructed. This reduces structureelement retrieval time considerably.

In the same way as the text element, the access mechanisms of theaccelerator element are to be programmed in such a way that acceleratorelements are stored and retrieved statically or dynamically. Staticimplies that references to accelerator elements are predefined in thesoftware. Dynamic implies that programs using the method according tothe invention can accept instructions as to how to use the acceleratorelements.

To enable structure element identification, the accelerator elementpreferably comprises some properties common to the structure element.These are CPT and INS identifying a basic occurrence in the structureelement file. The accelerator element also comprises a property toensure uniqueness (UNQ) in the case several basic occurrences can havethe same attribute reference representation.

Other properties of the accelerator element are an index, IDX,preferably used to define several reference representations for a basicoccurrence, and a property, ALT, preferably used to enable severalalternative reference representations for a specific index to a basicoccurrence. Finally the accelerator element contains an arbitrary numberof properties, REF1-REFn, containing the references.

The properties of the accelerator element, preferred terms and fieldsequence are presented in the following table, where the formatpreferably can be numeric:

Field# Fieldname Explanation 1 CPT Concept 2 INS Instance 3 IDXReference representation 4 ALT Alternative reference representations 5UNQ Optional, to create uniqueness 6 REF1 Reference #1 7 REF2 Reference#2 . . . . . . . . . n + 5 REFn Reference #nAccess Mechanisms for the Accelerator Element

There are several ways to retrieve individual elements in theaccelerator element file as described above. One way, in the followingcalled INDEX 1, is applying indirect retrieval using the vector {CPT,INS, IDX, ALT}, that is Field# 1, 2, 3 and 4. Another way, in thefollowing called INDEX 2, is applying indirect retrieval using thevector {CPT, IDX, REF1, . . . , REFn, UNQ}, that is Field# 1, 3, 6, . .. , n+5 and 5.

The access mechanisms of the accelerator element have the followingpurpose: INDEX 1 connects a basic occurrence in the structure elementfile with one or more reference representations, while INDEX 2 is usedfor retrieving a basic occurrence in the structure file using a set ofreferences.

An Example of Storing Data using the Invention

In the following an illustration of the storing method according to anembodiment of the invention is presented. The illustration was broughtfrom an application being a platform for modelling business operations,that is a set of utilities used to implement tailor-made systems foradministering business. The modelling is completely based on data.

Some predefined concepts used in the example are:

-   -   Constructor. A super-concept, from which all other concepts are        created. That is, all other concepts are concept values        (instances) of the super-concept, Constructor. All concepts have        a number of predefined properties; e.g Data type, Data format,        Redefine and a Bitmap property, holding, among other things, a        bit denoting multiple attribute representation (repeating        group). Constructor's Data type is Text. Hence all concepts        (instances of Constructor) are presented with text.    -   Redefine. A concept with the property Redefine is a redefinition        of another concept, that is, it shares its properties and value        domain.    -   Data type. All concepts have a data type. There are two        categories of data types: scalar and structure. “Numeric”,        “Date”, “Date&Time” and “Boolean” are scalar. All scalar data        are stored in fixed point numeric format. “Text”,        “Configuration” and “Record” are structures. Contents in scalar        concepts are identified and interpreted by their instance        numbers data format.    -   When assigning an attribute to a concept the understanding of        the concept will increase from the point of view of content. The        content of a structure-category concept is identified by its        instance number, but it is interpreted differently. Text is        interpreted through representation in the text element file.        Configuration is interpreted through a subset of or all of its        attributes, having the property “premise”. Record is interpreted        in an attribute context. Record is not represented in the        example.    -   Data format. Scalar data format denotes the total number of        integer and decimal digits in fixed point notation. This is        illustrated only with the concept thickness (see below −0.5 mm        is stored as 5). Instances of structure data have fixed format=8        digits. Text data is formatted with the maximum number of        characters.    -   Function. Instances of Function are arithmetic or logic        functions. The algorithm is described structurally using        attributes. This is not illustrated in the example.    -   Premise. An attribute, being part of the identification set of        attributes should have property Premise. Premise attributes are        enumerated from 1 to n.

Concepts used in the example are;

Pressed plate, a user defined thin, form-cut and pattern pressed sheetof metal. Its Data type=“Configuration”. A Pressed plate is interpretedthrough its attributes: Plate type, Metal and Thickness. Plate type isuser-defined with attributes Length, Width, Plate class and Standardthickness. The Standard thickness of a Pressed plate depends on Plateclass and the Metal-value. A Metal has a Specific weight.

The application has a rather simple storing structure:

Level 0 Level 1 Level 2 — — — Concept -----> Attribute -----> Property-----> Property

Concept is the highest level and can have one or more Attributes and/orone or more Properties. An Attribute can have one or more Properties.Attributes and Properties are references to Concepts. A Property imposeslimitations on its Concept or Attribute (e.g. data type, the validity ofa value . . . ).

To use the method according to the invention in a general manner,conventions for interpretation of predefined concepts and their valuesneed to be clarified:

-   -   Concept: A numeric representation of a concept definition. In        this data dictionary, a super-concept with text representation        “Constructor” is defined. This super-concept is the basis for        defining all other concepts. The super-concept, Constructor, has        numeric representation 1 (one).    -   Instance: A numeric representation of contents associated with a        Concept. Together Concept and Instance create a pair (Concept,        Instance) being a self-contained information carrier in program        systems using the method according to the invention. Examples:        (1,10) and (10,5). The interpretation of these pairs could be        (1,10)=(Constructor, “Name”) and (10,5)=(Name, “Adam”). In this        data dictionary the interpretation of (Concept, Instance) is as        follows: If Concept=1, that is the interpretation of        Concept=“Constructor”, the pair is interpreted as a concept        definition. If Concept>1 the pair is interpreted as concept        content. Concept must be >0.    -   BasicData is a basic occurrence of a pair (Concept,Instance). In        a structure element the BasicData is described using the vector:        {OWN,ATR,SRT,CPT,INS}={0,0,0,Cpt,Ins} where Cpt>0, and is        assigned a unique SID (structure element identifier). BasicData        is level 0 in the element structure.    -   Attribute widens the contents of a basic occurrence. The        Attribute structure element is described with the vector:        {OWN,ATR,SRT,CPT,INS}={Own,Atr,Srt,RefCpt,RefIns} where Own>0,        Atr>0, Srt>=0 and the pair (RefCpt,RefIns) can identify a basic        occurrence (0,0,0,RefCpt,RefIns). Attribute is level 1 in the        element structure.    -   Property interprets and limits the validity of a basic        occurrence or an attribute. Property is described in a structure        element using the vector:        {OWN,ATR,SRT,CPT,INS}={Own,0,0,PrpCpt,PrpIns} where OWN>0 and        the pair(PrpCpt,PrpIns) point at the basic occurrence of        (0,0,0,PrpCpt,PrpIns). Property is level 1 or 2 for the        structure element. There are two categories of properties:        Concept specific properties, being assigned contents when        defining a concept, and instance specific properties, being        assigned contents when assigning contents to the concept.    -   The application has about 50 predefined concepts. Other concepts        are added when modeling the application (i.e. implementing the        system).

The notation below complies with the formal description above. In thisexample the Data Dictionary structure elements for concept definitionsare as follows:

SID OWN ATR SRT CPT INS Explanation 1 0 0 0 1 1 Concept = Constructor:(Super-concept No.1) 2 0 0 0 1 2 Concept = Redefine: (ConceptRedefinition - No.2) 3 2 0 0 2 1 Concept = Redefine PRP: Redefine =Concept 4 0 0 0 1 8 Concept = Data type - No.8 5 0 0 0 8 1 Data type =Text 6 0 0 0 8 2 Data type = Numeric 7 0 0 0 8 3 Data type =Configuration 8 4 0 0 8 1 Concept = Data type PRP: Data type = Text 9 10 0 8 1 Concept = Concept PRP: Data type = Text 10 0 0 0 1 9 Concept =Format - No.9 11 0 0 0 1 19 Concept = Function - No.19 12 11 0 0 8 1Concept = Function PRP: Data type = Text 13 0 0 0 1 10 Concept =Bitmap - No.10 14 0 0 0 1 30 Concept = Premise - No.30 Concepts definedwhen modelling: 20 0 0 0 1 301 Concept = SpecificWeight No301 21 20 0 08 2 Concept = SpecificWeight PRP: Data type = Numeric 22 0 0 0 1 202Concept = Metal - No.202 23 22 0 0 8 1 Concept = Metal PRP: Data type =Text 24 22 1 0 1 301 Concept = Metal ATR 1: Concept = SpecificWgt 25 0 00 1 203 Concept = Thickness 26 25 0 0 8 2 Concept = Thickness PRP: Datatype = Numeric 27 25 0 0 9 21 Concept = Thickness PRP: Data format = 21(ie 99.9) 28 0 0 0 1 302 Concept = StdThickness 29 28 0 0 2 203 Concept= StdThickness PRP: Redefine = Thickness 30 0 0 0 1 303 Concept = Width31 30 0 0 8 2 Concept = Width PRP: Data type = Numeric 32 0 0 0 1 304Concept = Length 33 32 0 0 8 2 Concept = Length PRP: Data type = Numeric34 0 0 0 1 305 Concept = Plate class 35 0 0 0 1 201 Concept = Plate type36 35 0 0 8 1 Concept = Plate type PRP: Data type = Text 37 35 1 0 1 302Concept = Plate type ATR 1: Concept = StdThickn. 38 37 0 0 1 19 Concept= Plate type ATR 1: PRP: Concept = Function 39 37 0 0 10 8 Concept =Plate type ATR 1: PRP: BitMap = 8 (Mult atr) 40 35 2 0 1 303 Concept =Plate type ATR 2: Concept = Width 41 35 3 0 1 304 Concept = Plate typeATR 3: Concept = Length 42 35 4 0 1 305 Concept = Plate type ATR 4:Concept = Plate class 43 0 0 0 1 101 Concept = PressedPlate 44 43 0 0 83 Concept = PressedPlate PRP: Data type = Configuration 45 43 1 0 1 201Concept = PressedPlate ATR 1: Concept = Plate type 46 45 0 0 30 1Concept = PressedPlate ATR 1: PRP: Premise = 1 47 43 2 0 1 202 Concept =PressedPlate ATR 2: Concept = Metal 48 47 0 0 30 2 Concept =PressedPlate ATR 2: PRP: Premise = 2 49 48 3 0 1 203 Concept =PressedPlate ATR 3: Concept = Thickness 50 49 0 0 30 3 Concept =PressedPlate ATR 3: PRP: Premise = 3

The corresponding elements in the text element file, according to theinvention, for the basic occurrences in the structure elements of theData Dictionary above will be as shown in the table below:

CPT INS IDX ALT UNQ TXT 1 1 0 0 0 Concept 1 8 0 0 0 Data type 8 1 0 0 0Text 8 2 0 0 0 Numeric 8 3 0 0 0 Configuration 1 9 0 0 0 Data Format 119 0 0 0 Function 1 30 0 0 0 Premise Defined when modelling: 1 301 0 0 0Specific Weight 1 202 0 0 0 Metal 1 203 0 0 0 Thickness 1 302 0 0 0 StdThickness 1 303 0 0 0 Width 1 304 0 0 0 Length 1 305 0 0 0 Plate class 1201 0 0 0 Plate type 1 101 0 0 0 Pressed Plate

Examples of elements of data in the structure element file, according tothe invention, using the Data Dictionary as shown above are shown in thetable below:

SID OWN ATR SRT CPT INS Comment 101 0 0 0 301 4 Specific weight = 4kg/dm3 102 0 0 0 301 8 Specific weight = 8 kg/km3 103 0 0 0 202 1 Metal= Stainless 104 103 1 0 301 8 Metal = Stainless ATR 1: Specific weight =8 105 0 0 0 202 2 Metal = Titanium 106 105 1 0 301 4 Metal = TitaniumATR 1: SpecificWeight = 4 107 0 0 0 203 5 Thickness = 0.5 mm. 108 0 0 0203 6 Thickness = 0.6 mm 109 0 0 0 303 385 Width = 385 mm 110 0 0 0 303505 Width = 505 mm 111 0 0 0 304 940 Length = 940 mm 112 0 0 0 304 1348Length = 1348 mm 113 0 0 0 19 1 Function = StdGX-05 114 0 0 0 19 2Function = StdGX-06 115 0 0 0 305 1 Plate class = GX 116 0 0 0 201 1Plate type = GX-26 117 116 1 1 302 5 Plate type = GX-26 ATR 1: SRT 1:StdThickn = 0.5 mm 118 117 0 0 19 1 Platetype = GX-26 ATR 1: SRT 1: PRPFunction = StdGX-05 119 116 1 2 302 6 Plate type = GX-26 ATR 1: SRT 2:StdThickn = 0.6 mm 120 119 0 0 19 2 Plate type = GX-26 ATR 1: SRT 2:PRP: Function = StdGX-06 121 116 2 0 303 385 Plate type = GX-26 ATR 2:Width = 385.mm 122 116 3 0 304 940 Plate type = GX-26 ATR 3: Length =940 mm 123 123 4 0 305 1 Plate type = GX-26 ATR 4: Plate class = GX 1240 0 0 201 2 Plate type = GX-42 125 124 1 1 302 5 Plate type = GX-42 ATR1: SRT 1: StdThickn = 0.5 mm 126 125 0 0 19 1 Plate type = GX-42 ATR 1:SRT 1: PRP: Function = StdGX-05 127 124 1 2 302 6 Plate type = GX-42 ATR1: SRT 2: StdThickn = 0.6 mm 128 127 0 0 19 2 Plate type = GX-42 ATR 1:SRT 2: PRP: Function = StdGX-06 129 124 2 0 303 385 Plate type = GX-42ATR 2: Width = 385 mm 130 124 3 0 304 1348 Plate type = GX-42 ATR 3:Length = 1348 mm 131 124 4 0 305 1 Plate type = GX-42 ATR 4: Plate class= GX 132 0 0 0 101 1 PressedPlate = 1 (GX-26, Stainless, 0.5 mm) 133 1321 0 201 1 PressedPlate = 1 ATR 1: Plate type = GX-26 135 132 2 0 202 1PressedPlate = 1 ATR 2: Metal = Stainless 137 132 3 0 203 5 PressedPlate= 1 ATP 3: Thickness = 0.5 mm 139 0 0 0 101 2 PressedPlate = 2 (GX-42,Stainless, 0.5 mm) 140 139 1 0 201 2 PressedPlate = 2 ATR 1: Plate type= GX-42 142 139 2 0 202 1 PressedPlate = 2 ATR 2: Metal = Stainless 143139 3 0 203 5 PressedPlate = 2 ATR 3: Thickness = 0.5 mm

The corresponding elements in the text element file, according to theinvention, of basic occurrences in the structure elements as above willbe as shown in the following table:

CPT INS IDX ALT UNQ TXT 202 1 0 0 0 Stainless 202 2 0 0 0 Titanium 19 10 0 0 StdGX-05 19 2 0 0 0 StdGX-06 201 1 0 0 0 GX-26 201 2 0 0 0 GX-42305 1 0 0 0 GX

The corresponding elements in the accelerator file, according to theinvention, of basic occurrences in the structure elements as above willbe as shown in the following table:

REF REF CPT INS IDX ALT UNQ 1 REF 2 3 TXT 101 1 30 0 0 1 1 5PressedPlate GX-26, Stainless, 0.5 mm 101 2 30 0 0 2 1 5 PressedPlateGX-42, Stainless, 0.5 mm

This application of the accelerator elements has the objective of fastretrieval of basic occurrences using the Premises (IDX=30). The indexbecomes unique without using UNQ, whereas UNQ=0.

Find below a logical presentation of portions of the database aboveconcerning Pressed plate GX-42 (column header SID Nos 139-143, 113-114,115, 124-131, 103-112 and 101-102):

Concept -> Attribute -> Property (PressedPlate, 2) -> (Platetyp,“GX-42”) -> (Metal, “Stainless”) -> (Thickness, 0.5) (Platetype,“GX-42”) -> (StdThickn, 0.5) -> (Function, “StdGX-05”) -> (StdThickn,0.6) -> (Function, “StdGX-06”) -> (Width, 385) -> (Length, 1348) ->(Plate class, “GX”) (Function, “StdGX-05”) -> Not specified in theexample (Function, “StdGX-06”) -> Not specified in the example (Plateclass, “GX”) (Metal, “Stainless”) -> (SpecificWeight, 8) (Metal,“Titanium”) -> (SpecificWeight, 4) (Thickness, 0.5) (Thickness, 0.6)(Width, 385) (Width, 505) (Length, 940) (Length, 1348) (SpecificWeight,4) (SpecificWeight, 8)

Instances of Pressed plate are interpreted via the contents of thepremise attributes of Pressed plate, that is, the contents of Platetype, Metal and Thickness. Instances of Plate type and Metal areinterpreted via their text elements. Instances of Thickness areinterpreted via the Data format of Thickness.

(Function, “StdGX-05”) is part of the domain of rules. It governs theselection of plate thickness. Example: (Function, “StdGx-05”)−([Metal]EQUAL “Stainless”) (Function, “StdGX-06”)−([Metal] NOT EQUAL“Stainless”).

The notation {Metal} is interpreted as “the content of the concept Metalin the current context”.

The quantity Metal in a Pressed plate, can be calculated by a numeric(Function, “Plate weight”): {SpecificWeight}*{Thickn}*{Width}*{Length}.

Example of a Physical Implementation of the Method.

In the example above the three elements, according to the method of anembodiment of the invention, are implemented in a file system labelled“Index Sequential Access Method” (ISAM). The implementation uses only asmall part of the facilities of the file system. Generally, therequirements of the technique are that the file system can store andsort alphanumeric and numeric data. In addition the file system needs toallow two index files connected with each data file, and each indexcontaining up to 16 data fields. Below follows an example how thestoring preferably can be accomplished.

The structure elements are stored in three physical files; a data file,STRUCTUR.DAT, and two associated index files, STRUCTUR.IX1 andSTRUCTUR.IX2, together constituting the structure element file. The datafile sorts the elements by the property SID, being a number identifyingan element uniquely. This order of elements is denoted INDEX 0 for thestructure elements. In this file system SID is a number indicating theposition of the element (the record) in the data file, and is not storedas part of the element.

The two index files contain INDEX 1 and INDEX 2 as defined for thestructure element. The index files are maintained automatically by thefile system. In this file system, numeric data is stored in BCD-format(Binary Coded Decimal), and alphanumeric data in ASCII-format.

The structure file can preferably be dimensioned for 99,999,999structure elements. The formats of the properties of the structureelement file are:

STRUCTUR/SID: Integer (NumeriC identification not being stored)

STRUCTUR/OWN: 8 BCD-digits (4 bytes)

STRUCTUR/ATR: 2 BCD-digits (1 byte)

STRUCTUR/ALT: 6 BCD-digits (3 bytes)

STRUCTUR/CPT: 4 BCD-digits (2 bytes)

STRUCTUR/INS: 12 BCD-digits (6 bytes)

BCD is the storing format of the structure element properties. However,any sortable numeric format can be used. The field sizes of theproperties are governed by the requirements of the application.Essential for choosing format and field sizes is minimising thesecondary storage space used by each structure element. It should beadjusted to the block size of the storage device.

As all properties are defined as integers, the application using thestructure element needs to interpret the numeric contents to otherscalar types (Date, ASCII, Boolean, Numeric etc). The interpretation isgoverned by a “Data Dictionary”, itself stored as structure elements.

The text elements are stored in three physical files; one data file,TEXT.DAT, and two associated index files, TEXT.IX1 and TEXT.IX2,together constituting the text element file.

The two index files contain INDEX 1 and INDEX 2 as defined for the textelement. The index files are maintained automatically by the filesystem.

The text file can preferably be dimensioned for 1,000,000 elements. Theformats of the properties of the text element are:

TEXT/CPT: 4 BCD-digits (2 bytes)

TEXT/INS: 12 BCD-digits (6 bytes)

TEXT/IDX: 2 BCD-digits (1 byte)

TEXT/ALT: 2 BCD-digits (1 byte)

TEXT/UNQ: 8 BCD-digits (4 bytes)

TEXT.TXT: 50 ASCII-characters (50 bytes)

The size of the text field is a compromise considering the sizerequirements of the text representations and minimising the spacerequirements of the text elements. The block size used by this filesystem is a multiple of 64 bytes. The definitions also need to considerindex limitations of the file system.

The accelerator elements are stored in three physical files; a datafile, ACCEL.DAT, and two associated index files, ACCEL.IX1 andACCEL.IX2, together constituting the accelerator element file. The twoindex files contain INDEX 1 and INDEX 2 as defined for the acceleratorelement. The index files are maintained automatically by the filesystem.

The accelerator file is preferably dimensioned for 1,000,000 elements.The format of the properties of the accelerator element are:

ACCEL/CPT: 4 BCD-digits (2 bytes)

ACCEL/INS: 12 BCD-digits (6 bytes)

ACCEL/IDX: 2 BCD-digits (1 byte)

ACCEL/ALT: 2 BCD-digits (1 byte)

ACCEL/UNQ: 8 BCD-digits (4 bytes)

ACCEL/REF01: 8 BCD-digits (4 bytes)

ACCEL/REF02: 8 BCD-digits (4 bytes)

ACCEL/REF03: 8 BCD-digits (4 bytes)

ACCEL/REF04: 8 BCD-digits (4 bytes)

ACCEL/REF05: 8 BCD-digits (4 bytes)

ACCEL/REF06: 8 BCD-digits (4 bytes)

ACCEL/REF07: 8 BCD-digits (4 bytes)

ACCEL/REF08: 8 BCD-digits (4 bytes)

ACCEL/REF09: 8 BCD-digits (4 bytes)

ACCEL/REF10: 8 BCD-digits (4 bytes)

ACCEL/REF11: 8 BCD-digits (4 bytes)

ACCEL/REF12: 8 BCD-digits (4 bytes)

The number of reference fields in the element limits the number ofproperties that can be used in a compound retrieval. In the exampleabove, the accelerator element corresponds to an index definition withup to 12 properties. The application using the file definition usesmaximum 11 of the references.

Specialized Physical Implementation of the Method

The elements have a fixed logical structure. However, they are flexibleconsidering format and field property dimensioning. Defining elementfiles requires only a small number of parameters influencing needs forsecondary storage space and effectivity of the file system.

As the structural connection between element properties is predefined,general methods for maintenance and retrieval of data in the physicalfiles can be specified.

Specifying a file system suiting the elements and an interface definedby standard methods for maintenance and retrieval of data in the elementfiles together with a cache-system optimising the use of secondary andprimary storage, considerable effectivity improvements can be achieved.If such a file system is adjusted to and included in an operatingsystem, additional effectivity improvements can be achieved.

The elements can store any type of data. One advantage of selecting astandardised method for storing all types of data is that a combinationof customised electronic devices and standardised software in severallayers can create a common platform for all types of storing andretrieval needs.

The method according to an embodiment of the invention is universallyapplicable. Hence, it enables storing any type or structure of data. Themethod is based on the fact that structure elements are self-containedcarriers of information, represented by a pair: concept and conceptvalue, and context information adherent to it.

According to an embodiment of the invention, data can be organised inhierarchies of structure elements of arbitrary depth and complexity. Inspite of its simplicity, the method can reflect connection, context andmeaning, however complex, irrespective of types of data and how complexthe relations between data may be. Hence, the method represents afundamental framework for standardised physical data storage of alltypes of data.

The method according to an embodiment of the invention can beimplemented in virtually any reasonably advanced ISAM-file system, oranother suitable commercially available file system, or a file systemdeveloped and dedicated to this purpose.

The invention has now been described above with a preferred embodiment.However, it is obvious that many variations of it can be implemented. Asan example, it is possible to employ more, other and even fewer fieldsin the structure element, the text element and/or the acceleratorelement. It is also possible to use only the structure element, and notuse the text element or the accelerator element. Further, it is possibleto define different fields, as for example the identification,differently from what has been described above. Such and other kindredvariations must be seen as comprised by the invention as defined by theappended claims.

1. A method for storing data, comprising: organising data in structureelements, which are stored in a database file, each structure elementincluding two property fields interpreted as concept and concept valueand the concept characterizes the concept value; assigning a structureelement an identification property field enabling unique identificationof the structure element, and assigning the structure element at leastthree position property fields defining a relation between the structureelement and another structure element; and retrieving the data based onat least one of a group including the identification property field, theat least three position property fields and the two property fields,wherein one position property field governs vertical relations betweenstructure elements, thereby creating hierarchic relations betweenstructure elements, and wherein the other two position property fieldsgovern ordering of structure elements in hierarchic relations.
 2. Amethod according to claim 1, wherein the one position property fieldthat governs vertical relations is assigned a value of theidentification property of a structure element, with which saidstructure element is connected.
 3. A method according to claim 1,wherein the other two position property fields that govern orderingbetween structure elements in hierarchic relations are interpretedrespectively as attribute and attribute value ordering, allowing severaldifferent values of an attribute relating to another structure element.4. A method according to claim 1, comprising the further step, for atleast some of the elements in the structure element file, of storing, ina text element file, the properties, identifying a basic occurrence ofthe structure element file, together with a text property containing atext representation of at least a part of the information in acorresponding basic occurrence in the structure element file.
 5. Amethod according to claim 4, wherein text elements further comprise aproperty distinguishing several text elements and preferably containing0 or the identifying property of the corresponding basic occurrence. 6.A method according to claim 5, wherein the text elements furthercomprise an interpretation property defining how to interpret a textrepresentation.
 7. A method according to claim 6, wherein the textelements further comprise an interpretation alternative propertydefining alternative text representations of an interpretation.
 8. Amethod according to claim 4, wherein text elements further comprise aninterpretation property defining how to interpret a text representation.9. A method according to claim 8, wherein the text elements furthercomprise an interpretation alternative property defining alternativetext representations of an interpretation.
 10. A method according toclaim 4, wherein rules concerning selection of structure elements tohave text representation are predefined in software using the elements.11. A method according to claim 4, wherein rules concerning selection ofstructure elements to have text representation are defined dynamicallysupported by software using the elements.
 12. A method according toclaim 1, comprising the further step, for at least some of the elementsin the structure element file, of storing, in an accelerator elementfile, the properties, identifying a basic occurrence of the structureelement file, together with at least one reference property, intended tocontain some data from the structure element hierarchy of said basicoccurrence.
 13. A method according to claim 12, wherein the acceleratorelement further comprises a distinguishing property.
 14. A methodaccording to claim 13, wherein the distinguishing property contains 0 orthe identifying property of a corresponding basic occurrence in thestructure element file.
 15. A method according to claim 13, wherein theaccelerator element further comprises an interpretation property,defining how to interpret the accelerator representation.
 16. A methodaccording to claim 15, wherein the accelerator element further comprisesan interpretation alternative property, providing for alternativeaccelerator representations for a certain interpretation.
 17. A methodaccording to claim 12, wherein the accelerator element further comprisesan interpretation property, defining how to interpret acceleratorrepresentation.
 18. A method according to claim 17, wherein theaccelerator element further comprises an interpretation alternativeproperty, providing for alternative accelerator representations for acertain interpretation.
 19. A method according to claim 12, whereinrules concerning selection of structure elements to have data stored asreferences in the accelerator element file are predefined in softwareusing the elements.
 20. A method according to claim 12, wherein rulesconcerning selection of structure elements to have data stored asreferences in the accelerator element file are defined dynamicallysupported by software using the elements.
 21. A computer-readable mediumincluding executable instructions stored therein, which when executed bya computer system, causes the computer system to function as a databasesystem having the following data structure comprising: a database filestoring data organised in structure elements, each of the structureelements comprising two property fields interpreted as concept andconcept value and the concept characterizes the concept value, whereinthe structure elements are assigned an identification property fieldenabling unique identification of a structure element, and at leastthree position property fields defining a relation between the structureelement and another structure element, wherein one position propertyfield governs vertical relations between structure elements, therebycreating hierarchic relations between structure elements, and whereinthe other two position property fields govern the ordering of thestructure elements in hierarchic relations.
 22. The computer-readablemedium of claim 21, wherein the one position property field that governsvertical relations is assigned a value of the identification property ofa structure element, with which said structure element is connected. 23.The computer-readable medium of claim 21, wherein a the other twoposition property fields that govern ordering between structure elementsin hierarchic relations are interpreted respectively as attribute andattribute value ordering, allowing several different values of anattribute relating to another structure element.
 24. Thecomputer-readable medium of claim 21, further comprising the step, forat least some of the elements in the structure element file, of storing,in a text element file, the properties, identifying a basic occurrenceof the structure element file, together with a text property containinga text representation of at least a part of the information in acorresponding basic occurrence in the structure element file.
 25. Thecomputer-readable medium of claim 24, wherein text elements furthercomprise a property distinguishing several text elements.
 26. Thecomputer-readable medium of claim 25, wherein the distinguishingproperty contains 0 or the identifying property of the correspondingbasic occurrence in the structure element file.
 27. Thecomputer-readable medium of claim 25, wherein the text elements furthercomprise an interpretation property defining how to interpret a textrepresentation.
 28. The computer-readable medium of claim 24, whereintext elements further comprise an interpretation property defining howto interpret a text representation.
 29. The computer-readable medium ofclaim 24, wherein rules concerning selection of structure elements tohave text representation are predefined in software using the elements.30. The computer-readable medium of claim 24, wherein rules concerningselection of structure elements to have text representation are defineddynamically supported by software using the elements.
 31. Thecomputer-readable medium of claim 21, further comprising the step, forat least some of the elements in the structure element file, of storing,in an accelerator element file, the properties, identifying a basicoccurrence of the structure element file, together with at least onereference property, intended to contain some data from the structureelement hierarchy of the said basic occurrence.
 32. Thecomputer-readable medium of claim 31, wherein the accelerator elementfurther comprises a distinguishing property.
 33. The computer-readablemedium of claim 32, wherein the distinguishing property contains 0 orthe identifying property of a corresponding basic occurrence in thestructure element file.
 34. The computer-readable medium of claim 31,wherein the accelerator element further comprises an interpretationproperty, defining how to interpret accelerator representation.
 35. Thecomputer-readable medium of claim 31, wherein rules concerning selectionof structure elements to have data stored as references in theaccelerator element file are predefined in software using the elements.36. The computer-readable medium of claim 31, wherein rules concerningselection of structure elements to have data stored as references in theaccelerator element file are defined dynamically supported by softwareusing the elements.
 37. The computer-readable medium of claim 31,wherein the accelerator element further comprises an interpretationproperty, defining how to interpret the accelerator representation. 38.A method for creating a data model, comprising: entering data intoself-contained information carriers each including a concept and conceptvalue, the concept characterizing the concept value; assigning each ofthe self-contained information carriers an identification propertyenabling unique identification; assigning each of the self-containedinformation carriers at least three position properties to establishrelations between the self-contained information carriers; and creatinga data model using the self-contained information carriers and contextinformation held by the at least three position properties.
 39. Themethod of claim 38, wherein the data entered into the self-containedinformation carriers and the context information held by the at leastthree position properties are provided by an end-user.
 40. The method ofclaim 38, wherein the at least three position properties include oneposition property governing vertical relations between self-containedinformation carriers, thereby creating hierarchic relations between theself-contained information carriers, and two other position propertiesgoverning ordering of self-contained information carriers in hierarchicrelations.
 41. The method of claim 38, further comprising: retrievingthe data based only on the identification property assigned to each ofthe self-contained information carriers.
 42. The method of claim 38,further comprising: retrieving the data based on at least one of theconcept, concept value and at least three position properties.
 43. Themethod of claim 38, further comprising: retrieving the data based on atleast two of a group, which includes the concept, the concept value andthe at least three position properties, and the ordering of the at leasttwo of the group.